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REMARKS 

Claims 1,2, 12, 13 and 24 have been amended. No claims have been cancelled or 
added. Hence, Claims 1-24 are pending in the Application. 

As a preliminary matter, receipt of the Notice of Draftsperson's Patent Drawing 
Review is acknowledged. All drawings have been approved therein. 

Summary of Objections/Rejections 

Claim 2 has been objected to because a period has been omitted. Claim 2 has been 
amended to add the period. 

Claims 1, 5, 8, 13, 17 and 20 are rejected under 35 USC 102(e) as being 
anticipated by U.S. Patent No. 5,832,509, herein Mortis. 

Claims 2, 4, 9 - 1 1, 14, 16 and 21 - 23 are rejected under 35 USC 103(a) as being 
unpatentable over Mortis in view of U.S. Patent No. 5,758,345, herein Wang. 

Claims 3, 6, 15 and 18 are rejected under 35 USC 103(a) as being unpatentable 
over Mortis in view of U.S. Patent No. 6,035,298. 

Claims 12 and 24 are rejected under 35 USC 103(a) as being unpatentable over 
Mortis in view of U.S. Patent No. 5,822,749, herein Agarwal. 

Preliminary Remark Regarding Office Action's Explanation of Rejections 

The Office Action does not specify exactly what in the cited art corresponds to or 
constitutes each element or feature of the claims. In an Office Action "the particular part 
relied on must be designated as nearly as practicable . . . The pertinence of each reference, 
if not apparent, must be clearly explained ..." 37 C.F.R. § 1.104; MPEP 707. The present 
citations to the references do not provide Applicants with adequate notice or reasonable 
particularity with respect to the basis of the rejections. Instead, large portions of the 
references are simply identified in a non-specific way. As a result, Applicant has had to 
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engage in guesswork to determine the basis of rejections. In many cases, no 
corresponding structure or functions have been found by Applicant. 

Specifying exactly what elements in the cited art correspond to or constitute an 
element or feature of a claim greatly advances prosecution. If rejections of claims are 
maintained after this Office Action, Applicant respectfully requests that the subsequent 
Office Action specifying exactly what element(s) in the cited art correspond to an 
element or feature of a claim. For example, if a rejection of claim 1 is maintained using 
only Mortis, the Office Action should specify what exact element or elements in Mortis 
correspond or constitute a data block. 

Claims 1 and 13 

Claims 1 and 13, as amended, recites: 

concurrently with said first database system storing first database records in first 
data blocks having a first data block size, said first database system 
directly accessing a copy of second data blocks in which a second 
database system directly stored second database records; 

said second data blocks having at least one data block with a second data block 
size different than said first data block size; 

wherein said first data blocks . . . and . . . said second data blocks are . . . atomic 
units of storage allocated to store ... database records. 

Claims 1 and 13 have been amended to clarify that the first database system is 
concurrently handling data blocks of different sizes and that data blocks are atomic units 
of storage allocated to storing database records. Such features are not suggested much 
less disclosed by the cited art. 

Claims 1 and 13 have been rejected as being anticipated by Mortis. Mortis 
describes an approach for "adjusting the size of data as it is exchanged between a 
computer program and a database in situations when the computer program and the 
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database use different formats for the data which is to be exchanged." (Abstract) The 
computer program is referred to herein as the database client program. A datum is a field 
whose size and format may differ between a database client program and an IMS 
database. For example, the "part number field of converted computer programs had a 
larger data size (i.e., ten positions for a part number datum) than what the IMS database 
had for its part number field (i.e., eight positions for a part number datum)." (see also, 
Abstract, see datum 60 and first size 64 and second size 72 in FIG. 2, col. 3, lines 10 - 
14) "The present invention [in Mortis] allows the computer program conversion and 
expansion of Part Number fields independent to the database conversion." (col. 4, lines 
7-9) 

As those skilled in the art of database technology recognize, fields are elements of 
records. Mortis teaches that datums or fields are part of a segment. Mortis also teaches 
that a segment is a type of record to be inserted or updated in an IMS database. "The I/O 
area refers to the segment(s) or records retrieved or to be inserted or updated from/to an 
IMS database." (col. 4, lines 7 - 15) 

Thus, Mortis describes an approach that allows a client computer program and 
IMS database to use different formats for the same field. "This approach facilitates the 
conversion of large number of computer programs that access many databases that 
contain field(s) that need to be expanded. Also, the approach minimizes the number of 
program compiles, by keeping the databases in their current structure until all the 
computer programs have been converted to use the expanded field(s)." (col. 1, line 65 - 
col. 2, line 4) 

Apparently, the rejection is based on a correlation drawn by the Office Action 
between the IMS database of Mortis and the database systems claimed. However, what 
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element of Mortis the Office Action has correlated to a data block is, at best, unclear. 
Despite an exhaustive search, no corresponding structure or functions have been 
identified by Applicant. 

As amended, claims 1 and 13 clarify that a data block be an atomic unit of storage 
of database records. Mortis does not discuss anything about atomic units of storage 
allocated to store database records. For example, Mortis does not mention any thing 
about segments being stored in data blocks. 

Claims 1 and 13 further require that a database system concurrently handle data 
blocks of different sizes by storing database records in data blocks having a particular 
size while concurrently directly accessing a copy of other data blocks having another 
size. Mortis does not even discuss a database system's use of data blocks, or, in other 
words, does not discuss atomic units of storage in which to store database records, and 
therefore cannot possibly suggest much less disclose handling data blocks of multiple 
sizes, as claimed. 

Based on the foregoing, claims 1 and 13 are patentable. Reconsideration and 
allowance of claims 1 and 13 is respectfully requested. 
Claims 2 and 14 
Claims 2 and 14, further recite: 

the step of integrating said copy of said second data blocks within 
said first database system as a tablespace that includes said 
copy of said second data blocks. 

The Office Action admits that Mortis does not teach this further limitation, but 

alleges that Wang teaches this step. This allegation is incorrect. Claims 2 and 14 require 
more than just integrating a tablespace copy within a database system. Claims 2 and 14 
require integrating a tablespace with a data block size different than other data blocks 
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used by the database system to store database records. Wang fails to suggest much less 
disclose tablespaces having data blocks with different sizes. Thus, even it assumed that 
Wang teaches to integrate within a database a copy of a tablespace used by another 
database, it nevertheless fails to teach that the tablespace integrated has data blocks with 
a size different from other data blocks used by the database system to store data blocks, 
as claimed. Based on the foregoing, claims 2 and 14 are patentable. Reconsideration and 
allowance of claims 2 and 14 is respectfully requested. 
Claims 12 and 24 

Claims 12 and 24, as amended, recite; 

wherein said first database system includes a buffer cache in which said first 
database system stores data blocks of multiple sizes; and 

wherein said method further includes the step of concurrently storing said first 
data blocks and said second data blocks in said buffer cache. 

As amended, claims 12 and 24 require concurrently storing data blocks of a 
different size in a buffer cache. 

The Office Action has admitted Mortis fails to teach this feature of claims 12 and 
24, alleging instead that the feature is taught by Agarwal. Again, it is unclear what 
correlations are being drawn by the Office Action between items taught by Agarwal and 
elements of the claims. 

One item Agarwal teaches about are data pages. Data pages are physical units of 
storage that hold database records. "A typical database is an organized collection of 
related information stored as "records" having "fields" of information.... Between the 
actual physical database itself (i.e., the records contained in data pages stored on a 
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storage device) and the users of the system, a database management system or DBMS is 
typically provided as a software cushion or layer." (col. 1, lines 42 - 46) 

If the data pages are correlated to the data blocks as claimed, Agarwal 
nevertheless fails to teach to concurrently store data blocks of different sizes in a buffer 
cache. Agarwal does not suggest in any way much less disclose anywhere that data pages 
of a database system have a different size, and therefore cannot suggest in any way much 
less disclose concurrently storing data blocks of different sizes in a buffer cache. 

In the passages of Agarwal relied on for the rejection of claims 12 and 24, 

Agarwal teaches about I/O blocks and I/O block size or block (I/O) size. (See, for 

example, col. 8, lines 54 - 62) An I/O block, as taught by Agarwal, cannot be correlated 

to the data blocks claimed. The I/O block is storage used to hold data read from memory. 

Within each cache, the system can perform I/O operations in particular 
block sizes. For a given object (e.g., resident in a cache), the system can perform 
I/O operations using different block sizes, thus providing the ability to adjust the 
block size for a given object when the context of use of that object changes, (col. 
12, lines 44-49) 

An I/O block is not a data page. In fact, an I/O block may hold multiple 
data pages, (see below) 

Agarwal does teach that I/O block size may be varied to optimize database 
operations, resulting in more than one data page being read into an I/O block. For 
example: 

Accordingly, the approach adopted by the Optimizer is to employ 
2K block I/O technique while traversing the intermediate nodes (which 
typically are not contiguously stored). Once at the first data page of 
interest, however, the system at that point switches to large I/O technique 
until it has exhausted those rows satisfying the query. In the event that the 
cache overflows during the scan (e.g., the table is large and the query is 
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general in nature), the Optimizer further adopts a fetch-and-discard 
strategy, (col. 45, lines 21-28) 

While Agarwal teaches that I/O block size may be adjusted or varied to 
optimize a database operation, such a teaching is not tantamount to teaching that 
the size of an atomic unit of storage allocated for storing database records varies 
within a database system because an I/O block is by definition not an atomic unit 
of storage for database records. Agarwal explicitly teaches that an I/O block can 
contain multiple units of a type of storage unit allocated for storing database 
record, namely data pages, and therefore an I/O block cannot be atomic, at least 
with respect to storage units of database records. 

Based on the foregoing, claims 12 and 24 are patentable. Reconsideration 
and allowance of claims 12 and 24 is respectfully requested. 
Pending Claims 

The pending claims not discussed so far are dependant claims that depend on an 
independent claim that is discussed above. Because each of the dependant claims include 
the limitations of claims upon which they depend, the dependant claims are patentable for 
at least those reasons the claims upon which the dependant claims depend are patentable. 
Removal of the rejections with respect to the dependant claims and allowance of the 
dependant claims is respectfully requested. In addition, the dependent claims introduce 
additional limitations that independently render them patentable. Due to the fundamental 
difference already identified, a separate discussion of those limitations is not included at 
this time. 

For the reasons set forth above, Applicant respectfully submits that all pending 
claims are patentable over the art of record, including the art cited but not applied. 
Accordingly, allowance of all claims is hereby respectfully solicited. 
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The Examiner is respectfully requested to contact the undersigned by telephone if 
it is believed that such contact would further the examination of the present application. 



Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER 
LLP /] 



Dated: February 19, 2004 

Marcel 
Reg. No. 42,327 

1600 Willow Street 

San Jose, CA 95125 

Telephone No.: (408) 414-1080 ext.206 

Facsimile No.: (408) 414-1076 
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I hereby certify that this correspondence is being deposited with the United States Postal 
Service as first class mail in an envelope addressed to: Mail Stop Non-Fee Amendment, 
Commissioner for Patents, P.O. Box 1450, Alexandria, VA 22313-1450. 
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